Computer programmers today commonly design code in a programming editor, an integrated development environment (IDE), an Enterprise Development Technology test environment, or the like. A programming editor includes features for creating and editing source code. An IDE is a programming environment that has been packaged as an application program, typically consisting of a code editor, a compiler, a debugger, and a graphical user interface (GUI) builder. IDEs provide a user-friendly framework for many modem programming languages, such as Visual Basic, Sun Microsystems's Java™, and PowerBuilder. The IDE may be a standalone application or may be included as part of one or more existing and compatible applications. For example, Microsoft Word is designed primarily for word processing. Yet, Microsoft Word is able to incorporate a WordBasic program, which is an IDE. WordBasic provides additional functionality to word processing by allowing a programmer to build scripts to automate certain functions while writing and editing repetitive documents. At the same time, WordBasic may be used to write and debug an entire Visual BASIC program within Microsoft Word.
An example of an Enterprise Development Technology is .NET or Java 2 Platform Enterprise Edition (J2EE): .NET is a Microsoft operating system platform that incorporates applications, a suite of tools, and services to manipulate websites, and J2EE is a platform-independent, Java™-centric environment from Sun for developing, building, and deploying Web-based enterprise applications online. The J2EE platform consists of a set of services, Application Programming Interfaces (APIs), and protocols that provide functionality for developing multi-tiered, Web-based applications. Currently, to test these technologies, a programmer typically either uses a test environment that is able to run the underlying infrastructure or manually deploys a program on the test environment. For example, a programmer may test a Java™ Servlet or J2EE Enterprise JavaBeans (EJB) of a Java™ API to define a component architecture for multi-tier client/server systems. The programmer would test the Servlet or EJB in an Application Server instance that has a WebContainer or EJBContainer in which the code may run. These containers manage the runtime infrastructure to allow the Servlet or EJB to run properly.
Often while developing code within a program editor, IDE, or an Enterprise Development Technology test environment, a programmer would like to quickly verify the behavior of a self-contained code segment. Self-contained refers to code that does not rely on other components to operate. In addition, though the value of a variable may change, the actions of the code during execution remain static. To illustrate, the programmer may be parsing a string, binary shifting, performing logical operations, or formatting. Unfortunately, the programmer is unable to verify unfinished code or unfamiliar code without finishing the code, testing the entire code, fleshing out a temporary source program, and managing the workspace involved.
Often when a programmer designs an application, the programmer codes in a series of source files. Managing test files of this series of source files is cumbersome. Typically, a programmer tests code by writing several smaller files to test segments of each source file of code. While testing the segments, often the programmer tweaks the code to test small changes in the code. Then, the programmer is left with several test codes of separate updates to the series of source files. Managing the updates and deleting the test codes is time-consuming, frustrating to decipher, and risky to ensure the preservation of the ideal update per area of code.
Two approaches are typical in the art for testing a code segment. In a first approach, a programmer manually creates a test program, compiles the program, and then executes the program to investigate the behavior. Although logically effective for testing the code segment, this approach is less than optimal for time and space efficiency for several reasons. One, this approach is error prone because a new source file must be created and imports are manually resolved. Additionally, the steps within this approach add duration to code development. Finally, this approach clutters the working environment with additional test programs to manage, use to incorporate knowledge into the original source program, and delete without losing modifications. Even if a programmer does not use additional source files to test, the programmer exerts more effort to keep the initial work environment clean and clear by deleting all test statements such as print statements of values of variables near any variable reassignments in the code.
Another approach is to employ debugging features of an IDE. Breakpoints and other debugging features aid a programmer in viewing and scrutinizing execution of a source file; however, all of these features complicate the examination with strict requirements of the source file. First, a breakpoint is a location in programming code that, when reached, triggers a temporary halt in the program. Programmers typically use breakpoints to test and debug programs by causing the program to stop at scheduled intervals and examining the status of the program in stages. Undoubtedly, one of the most common debugging procedures is to set breakpoints that will allow the inspection of variables and the values inside conditional statements or loops. This method, however, requires establishing a source file that is fully able to be translated from a programming language into executable computer-readable machine code and running the beginning of the source file up to the breakpoint.
Another debugging feature is, for example, the “inspect” feature of WebSphere Studio Application Developer product (WSAD), an open, portable, universal tooling platform and integration technology developed by International Business Machines, Inc. While debugging an application, this feature will allow a programmer evaluate expressions in a WSAD Debug editor. The programmer selects the entire line where the breakpoint is set, and from the context menu, selects the Inspect option. An Expressions view of a Display window then presents the value of the expression. But, the variable or expression is evaluated merely in the context of the current stack frame and the programmer must keep track of the variable or expression through the context of the entire source program up to the breakpoint. Another difficulty of this approach is the requirement that the developed source program be compliable and executable.
One more debugging feature is a feature such as Hotswap Bug Fixing, which is available while running Eclipse 2.0.2 or 2.1 with Java Virtual Machine 1.4. Created by International Business Machines, Inc., Eclipse is an extensible open source IDE for the development of highly integrated tools in a platform- and language-neutral industry framework. Hotswap Bug Fixing allows a programmer to modify a source file during a debugger session, creating an advantage over modifying the source file by exiting the application, changing the code, recompiling, and then beginning another debugging session. Although it is more convenient to modify code during a debugging session without having to compile and execute the code each time, this feature also requires establishing a fully compliable source file and running the code segment to be evaluated in conjunction with code appearing before the code segment in the source file. Running from the beginning of the code up through the code segment may involve time-consuming interaction with the output, which complicates testing one code segment.
In addition, these debugging features require the source file to have an entry point. An entry point is a point in code that indicates where to begin compiling or executing the source file. For example, code written in C includes an “{” and ”}” to delineate the main program. Accordingly, execution begins at the entry point, the “{”, and code statements direct the processing flow subsequently until flow ends at the “}”. Because WSAD's inspect feature requires an entry point, the inspect feature does not aid a programmer who would like to inspect how a function within a standard library operates. In this example, to use the inspect feature to test a library function, the programmer would write a separate testing program to meet the requirements of being compilable and executable and containing an entry point; then, the programmer would use the separate testing program to call the library function. An additional drawback of the WSAD inspect feature is that this approach requires running the entire program if the source program is not self-executable. Ultimately, this approach focuses on the testing phase of the code life cycle rather than the development or coding phase.
In view of the above, various needs exist in-the art for testing a code segment in a program editor or integrated development environment. More particularly, needs exist for techniques for testing of a code segment that are less time consuming and less cluttering.